Proposal for Lisp Compiler Maintenance Manual

				Whitfield Diffie

	At present, anyone wishing to use the Stanford Lisp  1.6  compiler  more
subtly  than compiling a list of files in the usual way, is hindered by the need
to study  a  rather  substantial  amount  of  well  organsied  but  complex  and
undocumented  code.  The proposed manual would remedy this by making available a
clear explanation of all aspects of the compiler's sturcture and operation.

This manual will contain:

1) An explanation of each routine, sufficient  to  make  it  functioning  clear.
This  will  include  its overall behavior, the conventions and circomstances for
its use, and an explanation of each non-obvious line of code it contains.

2) A general explanation of the compiler's  operation  sufficient  to  give  the
casual  reader  an understanding of its operation and general layout. I envision
an turorial version of what we would write if publishing a paper on it.

3) Careful explanation of several  general  mechanism's,  not  all  explicit  to
compiling,  which are used throughout, an may be of interest to Lisp programmers
in general.

4) A thorough explanation of the data structures.

5) An index of the various global variables to accompany #4.

6) The compiler is highly extensible, though this feature has been of little use
due  to  lack  of  documentation.  An explanation of how the arrange for special
compilation of new classes of functions introduced  by  the  programmer  without
modification of the compiler itself will be included.

7)  The  built in debugging machinery of the compiler will be explained, thereby
giving the prospective modifier the basic tools needed for the work.

8) The use of the compiler, to compile files, to compile from memory  etc.  will
be  explained.   This  will include explanation of a variety of global variables
giving default devices, modes etc.

9) An index of the above sections by both the terms used and terms standard  for
concepts in compiling.

Cost Estimate:

	The  Stanford  Lisp  compiler  is  approximately  fifty pages in length,
containing some three hundred s-expressions of which two hundred and  fifty  are
routine  definitions.   There are about two thousand five hundred lines of code.
The document described above will probably be of comperable length.  Presumeably
no  more  than  a  factor  of  two larger or smaller. I base my extimate of cost
primarily on the number of routines, though it appears consistent with the  size
of  the  other  parameters.   Although most of these routines are both small and
simple, the remainder are often both large and complex.   I estimate and average
of one hour apiece.

My  present  hourly salery from the Stanford EE department which employs me half
time is $7.18 per hour.  Figuring a charge of  1.5  times  that  per  hour,  and
allowing  for  a  30% overrun, as suggested gives $14 per hour.  For two hundred
and fifty hours, this comes to  $3500.    Devlivery  will  depend  on  my  other
commitments, but should be no worse than three months, or 1/2 time.